Initial configuration

In this section, it is assumed that

• ProtectToolkit-C has been successfully installed on your system. For more information, refer to ProtectToolkit 7 Software Installation.

• You can access the ProtectToolkit-C utilities used to carry out configuration tasks. For more information, refer to Configuration items.

Synchronizing the HSM time with the system clock

When setting up a ProtectServer 3 HSM for the first time, use the ctconf utility to synchronize the HSM with the system clock, to ensure that logs are produced with the correct time stamps.

To synchronize the HSM time with the system clock

Use the following command:

ctconf -t

Setting the Admin token PINs

Following an initial installation or tamper event, it is necessary to introduce the Administrator and Administration Security Officer (ASO) user roles by setting their initial PINs. This is done using the ctconf utility. For more information about PINs, including details of what constitutes a valid PIN, refer to PINs and passwords.

To set the Admin token PINs

1. From a command prompt, enter ctconf and press Enter.

   You are prompted to set the ASO PIN.

   Note

   If you intend to operate the ProtectServer 3 HSM with firmware 7.03.00 in FIPS Mode, set a PIN that is 8 to 32 characters-long.

2. Enter the ASO PIN and press Enter. Enter this same PIN again for confirmation.

   Note

   PIN characters or asterisks (*) do not appear on screen while the PIN is being typed. For details of what constitutes a valid PIN see PINs and passwords.

   If you intend to operate the ProtectServer 3 HSM with firmware 7.03.00 in FIPS Mode, set a PIN that is 8 to 32 characters-long.

3. Enter the Administrator PIN and press Enter. Enter this same PIN again for confirmation.

4. On board each HSM is a real-time clock (RTC). If the RTC is out of synchronization with the host system clock, you are then prompted to allow synchronization. To synchronize the RTC to the host system clock type Y and then Enter. Otherwise, enter N to abort.

   After successful completion of the above, HSM configuration details are displayed. For example:

   Current Adapter Configuration for Device 0:
   Model             : PSI-E2:PL220
   Serial Number     : 518687
   Adapter Clock     : 30/08/2016 15:07:04 (-5:00+DST)
   Battery Status    : GOOD
   Security Mode     : Default (No flags set)
   Transport Mode    : None
   FM Support        : Enabled
   FM Status         : No FM downloaded yet
   Open Session Count: 0
   Number of Slots   : 1
   RTC Adjustment Access Control: Disabled
   

   The following message is then displayed:

   PLEASE NOTE that the firmware allows FMs to be downloaded; but the "Tamper 
   before upgrade" security flag is not set. To protect existing keys against a
   possible threat of a rogue FM, this flag should be set (using 'ctconf -ft')
   

   Note

   An FM is a functionality module. For more information, refer to Installing a functionality module.

   Finally, the utility closes and the operating system command prompt returns.

Configuring the ProtectServer owner and/or identity certificates

ProtectToolkit 7 allows you to generate an identity key and certificate on the HSM, ensuring that cryptographic objects can be replicated only to other ProtectServer 3 HSMs you control, and to secure messages between the HSM and PTK.

For details and procedures related to generating identity keys and certificates on the HSM, refer to ProtectServer owner and identity certificates

Selecting and setting a security policy

A security policy is a set of security settings that control how ProtectToolkit-C is allowed to function. Setting the security policy is the most important part of ProtectToolkit-C initial configuration.

A number of security settings offered by ProtectToolkit-C can be used to implement typical security policies that meet certain standards or satisfy application integration requirements. Alternatively, custom security policies can be implemented.

For full details and instructions, refer to Security policies and user roles.

Setting up slots

The Administrator will have to decide on the number of slots required for the particular environment. In its default initial configuration, ProtectToolkit-C will have one User slot, one Admin slot and one slot for each connected smart card reader.

As a general guide, the Administrator should create as many slots as there are applications, or users, that will want to perform PKCS#11 processing. This configuration allows for individual applications to be completely separate from each other.

For more information about the types of slots and tokens, refer to Slots and tokens.

To create new user slots

Use the ctconf utility with the -c switch.

Slot Setup Examples

ctconf -c2

Since only the Administrator is authorized to create new slots, you will be prompted for the Administrator PIN.

This command will create two new User slots, each with an associated token. To check that the slots were created, use the ctstat utility, which will report information on all current slots and tokens.

Slots are numbered consecutively, with the last or highest slot number always being the Admin slot.

The current configuration is:

If two slots are added, the configuration becomes:

Multiple adapter HSMs

When multiple HSM adapters (such as the ProtectServer 3 PCIe HSM) are installed in a single machine, there will be multiple Admin slots - one per HSM. The slots for the second HSM will appear directly following the slots for the first HSM. For example, if two HSMs were installed with their default configuration, slot 0 and slot 2 would be user slots, slots 1 and 3 would be the Admin slots for the first and second HSM respectively. The diagram below illustrates this slot numbering scheme.

Slot numbering scheme for two ProtectServer 3 PCIes installed in a single machine

Token initialization

After creating a slot within ProtectToolkit-C, the token within that slot must be initialized so it can be used by an application. This initialization will assign a label and set up the Security Officer and User PINs for that token. In addition to initialization of User slots, this procedure is also applicable to any smart card tokens used with ProtectToolkit-C.

The party responsible for token initialization depends on the Security Policy that has been set for the adapter. In the case where ‘clear PINs’ are allowed, any user taking on the role as that token’s Security Officer can perform the token initialization. In the case where ‘clear PINs’ are not allowed, only the Administrator can perform the token initialization. For more information on Security Policies, refer to Security policies and user roles.

To initialize a token

The ctconf utility is used by the Administrator to initialize a token on a particular slot. Once a token is initialized, it can only be reinitialized, or reset, by the token SO, using the ctkmu or ctconf utility.

Token initialization examples

ctconf -n1

This example will initialize token 1 in slot 1.

ctconf will prompt for the token label to be entered, followed by the token SO PIN.

Following initialization of a token, the token SO should change the PIN set by the Administrator with the ctkmu utility. Instructions are provided in Changing a User or Security Officer PIN.

Next, the token SO must initialize the token user PIN using the ctkmu utility.

ctkmu p -s2

This example will initialize the user PIN on token 2. The SO PIN will be prompted for, followed by a prompt for the new User PIN.

Once both the SO and User PINs have been selected, the token is ready for use with an application. The User is advised to change his/her PIN from the one the SO assigned by repeating the above command.